Piping Chunk 0.4.0 - 0.5.0のVerification Codeの中間者攻撃を成立させる
まず、中間者攻撃が成立させる話であり。中間者がいなければエンドツーエンドで暗号化されている。また、Piping ServerをHTTPSで運用している場合、サーバー↔クライアントで中間者攻撃が成立するのはSSLを信じないことにつながると思う(ドメイン乗っ取られたとかあるかもしれないが)。
成立させる流れ
0.4.0と0.5.0は同じ方式でVerification Codeを生成している。
前提として、Piping Serverが動作しているサーバーの権限を持っている必要がある。
つまり通常のPiping Serverを止めたり、変更したPiping Serverをそのかわりに起動させたりすることができるということ。
実際に、中間者攻撃を成立できるかは試していない。あくまでも思考上。 登場人物は3人。送信者S、中間者M、受信者R。
送信者S => 受信者Rにファイルを送ろうとしている。
送信者Sが楕円曲線ディフィー・ヘルマン鍵共有で2つの公開情報を送る
「Verification Code生成用公開鍵: $ Vpub_S」と「共通鍵生成用公開鍵: $ Epub_S」
どちらの公開鍵も生成方法は同じ
中間者Mが$ Vpub_Sと$ Epub_Sを持っておく。まだ返事はしない。
受信者Rが楕円曲線ディフィー・ヘルマン鍵共有で2つの公開情報を送る
「Verification Code生成用公開鍵: $ Vpub_R」と「共通鍵生成用公開鍵: $ Epub_R」
中間者Mが$ Vpub_Rと$ Epub_{M_S}を送信者Sに送る
$ Epub_{M_S}は中間者Mが生成した楕円曲線ディフィー・ヘルマン鍵共有で共通鍵生成用公開鍵
つまり、中間者は、受信者Rの共通鍵生成用公開鍵のみを改ざんして送信者Sに送っている $ Vpub_Rは改ざんしたりしない
悪い中間者がいなければ$ Epub_Rが送られるはずだが、$ Epub_{M_S}が送られているということ
これで送信者Sと中間者Mの間で共通鍵$ Epriv_{M_S}が作れる
$ Epriv_{M_S}の生成は、$ Epub_Sと$ Epub_{M_S}を用いて生成される
($ Epub_Sと$ Epub_{M_S}は楕円曲線ディフィー・ヘルマン鍵共有で作られた公開鍵)
中間者Mが$ Vpub_Sと$ Epub_{M_R}を受信者Mに送る
送信者Sに送った上記と同様
$ Vpub_Sは改ざんせずに、$ Epub_Sの代わりに$ Epub_{M_R}が送られる
これで受信者Rと中間者Mの間で共通鍵$ Epriv_{M_R}が作れる
$ Epriv_{M_R}の生成は、$ Epub_Rと$ Epub_{R_S}を用いて生成される
Verfication Code $ Veriも送信者Sと受信者Rの間で同じ値が生成される
$ Veriの生成は、$ Vpub_Sと$ Vpub_Rを用いる。
中間者Mは$ Veriは生成できない
ただ送信者と受信者の$ Veriの値は同一になる。同一だから同じだとして検証できてしまう。
($ Veriは暗号化するようの共通鍵と関係がなく生成される)
中間者MはVerification Code $ Veriを知るすべはない。でも送信者と受信者は同じ$ Veriが生成できるためVerification Codeによる検証ができる。
送信者が送るデータは
$ Epriv_{M_S}でS <=> Mの間で暗号化され、
$ Epriv_{M_R}でM <=> Rの間で暗号化される。
中間者Mは$ Epriv_{M_S}と$ Epriv_{M_R}を知っているため、復号したデータを手に入れることができる。
アイデアをまとめると、Verification Code生成用の公開鍵は改ざんせずに、共通鍵生成用の公開鍵のみを改ざんすること。 上記の流れでは、送信者Sが先に楕円曲線ディフィー・ヘルマン鍵共有で2つの公開情報を送っているが、受信者Rが先に楕円曲線ディフィー・ヘルマン鍵共有で2つの公開情報を送っても同じように成立させられる。Verfication Codeと共通鍵生成の流れは、送信者Sも受信者Mもシンメトリックな動作をする。 (シーケンス図のほうがわかりやすいはず)